The present invention relates to the physical locations of logical objects in mass storage devices and, in particular, to a method and system for providing logical-object-to-physical-location translations and for providing physical separation of logical objects, where the translations and physical separations are requested by high-level application programs executed on a host computer or human users interacting with a host computer that accesses and manipulates logical objects stored on a remote mass storage device, such as a disk array.
The present invention relates to the access and manipulation of logical objects stored on remote mass storage devices by high-level application programs executing on host computers connected to the mass storage devices. The present invention is described and illustrated with reference to an embodiment partially included in a disk array controller that services I/O requests from a number of remote computers. However, alternative embodiments of the present invention may be employed in controllers of many other types of storage devices as well as in general electronic data storage applications.
FIG. 1 illustrates data storage within a platter of a hard disk drive. The platter is a thin disk, coated with a magnetic medium, such as iron oxide. Data can be stored in tiny areas of the surface of the platter having induced, stable magnetic fields. The surface of the disk platter 102 is divided into concentric rings, or tracks, such as tracks 104-105 in FIG. 1. Current disk platters contain many thousands of tracks. Each track is divided into radial segments, or sectors, such as sector 106 of track 104 in FIG. 1. Sectors each normally comprise a fixed number of bytes, normally 256, 512, 1024, or 2048 bytes. Data is normally retrieved from, and stored to, a hard disk drive in units of sectors. Once a sector is read from a disk and stored into computer memory, a program may access individual bytes and bits within the sector by accessing the random memory in which the sector is stored. Thus, the physical location of data on a disk platter can be described by a starting location and an ending location, each location specified as a track/sector/byte triple. Normally, a hard disk drive contains a number of platters aligned in parallel along a spindle passing through the center of each platter. Typically, the track and sectors of the platter can be thought of as aligned to form cylinders spanning the platters. In such hard disk drives, the physical address of a byte of data may also be described by a track/sector/byte triplet, where the byte within an aligned group of sectors composing a section of a cylinder are consecutively ordered.
FIG. 2 is a block diagram of a standard disk drive. The disk drive 201 receives input/output (xe2x80x9cI/Oxe2x80x9d) requests from remote computers via a communications medium 202 such as a computer bus, fibre channel, or other such electronic communications medium. For many types of storage devices, including the disk drive 201 illustrated in FIG. 2, the vast majority of I/O requests are either READ or WRITE requests. A READ request requests that the storage device return to the requesting remote computer some requested amount of electronic data stored within the storage device. A WRITE request requests that the storage device store electronic data furnished by the remote computer within the storage device. Thus, as a result of a READ operation carried out by the storage device, data is returned via communications medium 202 to a remote computer, and as a result of a WRITE operation, data is received from a remote computer by the storage device via communications medium 202 and stored within the storage device.
The disk drive storage device illustrated in FIG. 2 includes controller hardware and logic 203 including electronic memory, one or more processors or processing circuits, and controller firmware, and also includes a number of disk platters 204 coated with a magnetic medium for storing electronic data. The disk drive contains many other components not shown in FIG. 2, including read/write heads, a high-speed electronic motor, a drive shaft, and other electronic, mechanical, and electromechanical components. The memory within the disk drive includes a request/reply buffer 205 which stores I/O requests received from remote computers and an I/O queue 206 that stores internal I/O commands corresponding to the I/O requests stored within the request/reply buffer 205. Communication between remote computers and the disk drive, translation of I/O requests into internal I/O commands, and management of the I/O queue, among other things, are carried out by the disk drive I/O controller as specified by disk drive I/O controller firmware 207. Translation of internal I/O commands into electromechanical disk operations in which data is stored onto, or retrieved from, the disk platters 204 is carried out by the disk drive I/O controller as specified by disk media read/write management firmware 208. Thus, the disk drive I/O control firmware 207 and the disk media read/write management firmware 208, along with the processors and memory that enable execution of the firmware, compose the disk drive controller.
Individual disk drives, such as the disk drive illustrated in FIG. 2, are normally connected to, and used by, a single remote computer, although it has been common to provide dual-ported disk drives for use by two remote computers and multi-port disk drives that can be accessed by numerous remote computers via a communications medium such as a fibre channel. However, the amount of electronic data that can be stored in a single disk drive is limited. In order to provide much larger-capacity electronic data storage devices that can be efficiently accessed by numerous remote computers, disk manufacturers commonly combine many different individual disk drives, such as the disk drive illustrated in FIG. 2, into a disk array device, increasing both the storage capacity as well as increasing the capacity for parallel I/O request servicing by concurrent operation of the multiple disk drives contained within the disk array.
FIG. 3 is a simple block diagram of a disk array. The disk array 302 includes a number of disk drive devices 303, 304, and 305. In FIG. 3, for simplicity of illustration, only three individual disk drives are shown within the disk array, but disk arrays may contain many tens or hundreds of individual disk drives. A disk array contains a disk array controller 306 and cache memory 307. Generally, data retrieved from disk drives in response to READ requests may be stored within the cache memory 307 so that subsequent requests for the same data can be more quickly satisfied by reading the data from the quickly accessible cache memory rather than from the much slower electromechanical disk drives. Various elaborate mechanisms are employed to maintain, within the cache memory 307, data that has the greatest chance of being subsequently re-requested within a reasonable amount of time. The disk array controller 306 may also elect to store data received from remote computers via WRITE requests in cache memory 307 in the event that the data may be subsequently requested via READ requests or in order to defer slower writing of the data to physical storage medium.
Electronic data is stored within a disk array at specific addressable locations. Because a disk array may contain many different individual disk drives, the address space represented by a disk array is immense, generally many thousands of gigabytes. The overall address space is normally partitioned among a number of abstract data storage resources called logical units (xe2x80x9cLUNsxe2x80x9d). A LUN includes a defined amount of electronic data storage space, mapped to the data storage space of one or more disk drives within the disk array, and may be associated with various logical parameters including access privileges, backup frequencies, and mirror coordination with one or more LUNs. LUNs may also be based on random access memory (xe2x80x9cRAMxe2x80x9d), mass storage devices other than hard disks, or combinations of memory, hard disks, and/or other types of mass storage devices. Remote computers generally access data within a disk array through one of the many abstract LUNs 308-315 provided by the disk array via internal disk drives 303-305 and the disk array controller 306. Thus, a remote computer may specify a particular unit quantity of data, such as a byte, word, or block, using a bus communications media address corresponding to a disk array, a LUN specifier, normally a 64-bit integer, and a 32-bit, 64-bit, or 128-bit data address that specifies a LUN, and a data address within the logical data address partition allocated to the LUN. The disk array controller translates such a data specification into an indication of a particular disk drive within the disk array and a logical data address within the disk drive. A disk drive controller within the disk drive finally translates the logical address to a physical medium address. Normally, electronic data is read and written as one or more blocks of contiguous 32-bit or 64-bit computer words, the exact details of the granularity of access depending on the hardware and firmware capabilities within the disk array and individual disk drives as well as the operating system of the remote computers generating I/O requests and characteristics of the communication medium interconnecting the disk array with the remote computers.
While the disk array, as described above, provides data storage within, and addressed relative to, LUNs, high-level application programs (xe2x80x9cAPPsxe2x80x9d) executing on host computers access data stored within LUNs via a number of higher-level abstractions. FIG. 4 illustrates the hierarchical data abstraction levels within a host computer/disk array system. Each block in FIG. 4 represents a separate program, program/hardware, or hardware component within the host computer/disk array system. As discussed above, the disk array 402 accesses data stored within internal disks via internal physical addresses that each contain indications of a disk, a track within a disk, a sector within the track, and a byte within the sector. However, as discussed above, the disk array provides data access and storage to virtual storage spaces, called LUNs, each LUN having some fixed number of addressable units, such as bytes. The two abstractions 404 and 406 in FIG. 4 are linked to operating system components that execute within the operating system of a host computer interconnected with a disk array. The first component is a volume manager 404. This component interacts with a disk array via a communications medium, accessing and storing data relative to the LUN abstraction provided by the disk array. The volume manager 404 presents a different interface to components above the volume manager in the abstraction hierarchy. The volume manager provides volumes which have volume names and which contain a linear address space of bytes, words, or some other convenient addressable entity. The volume manager may map a volume onto one or more LUNs, translating volume-relative addresses received from higher-level components into LUN-based data addresses that the volume manager then passes to the disk array. In addition, the volume manager can increase the size of a logical volume using an arbitrary LUN, which can quickly change the physical location of the entirety of a logical object.
The next highest component shown in FIG. 4 is the operating system""s file manager 406. The file manager provides a logical object interface to the highest-level component, an executing APP 408. Most logical objects currently provided by file managers and used by APPs are called xe2x80x9cfiles.xe2x80x9d Files are arbitrarily sized, consecutive sequences of data bytes, described by file names, that are stored on a mass storage device and read from, and written to, operating-system-provided I/O commands. A file manager provides a hierarchical, multi-component file name space to allow an APP or user to organize files within hierarchical directories. The file manager translates a file name, including the directory and subdirectory prefixes within the file name, to a range of consecutive addressable entities, such as bytes, within a volume. An APP 408, or a human user interacting with the APP, stores data to, and accesses data from, a mass storage device, such as a disk array, in terms of named logical objects.
Normally, a human user or APP is not concerned with the actual physical location of logical objects. Logical objects may, for example, span a number of different LUNs, each of which span a number of different hard disk drives within a disk array. There are, however, cases where a human user or APP may be very concerned about the physical locations of data stored within logical objects. In many systems, logical objects are replicated in order to provide greater reliability. If the storage medium on which a first logical object is stored becomes corrupted, then the second logical object, a copy of the first logical object, can be accessed instead. However, if both logical objects, or portions of the logical objects, are stored on the same hard disk drive, a single hard disk drive failure may destroy both logical objects and may therefore constitute an unrecoverable error. No matter how many copies of a logical object are saved, because portions of the logical objects may end up residing on a common disk drive, a user or application program may not be guaranteed of being able to recover a single good copy of the logical object following a hard disk drive failure. Of course, a user or APP may direct copies of the logical objects to be stored on different disk arrays or other types of mass storage devices. However, there may be additional virtual address layers between disk drives and a host computer, so that an APP or user may not, in fact, be able to determine from a logical object name on which mass storage device the logical object resides.
Various utilities and support functionality within operating systems and disk array controllers have been developed in order to facilitate translation of logical object names to physical storage locations. FIG. 5 graphically represents two translation mechanisms that facilitate translation of logical object names to physical storage locations. Within a disk array controller 502, a LUN Manager, or LUN Manager functionality, may translate a LUN into one or more physical extents, each physical extent comprising a starting point and ending point on a hard disk drive, each extent expressed as indications of a disk, a track within the disk, and a sector within the track. The LUN Manager 504, in addition to providing LUN to physical location translations, can also forcibly relocate a first LUN to different hard disks within the disk array so that the first LUN does not overlap a second LUN, or, in other words, so that no data of the first LUN is stored on a hard disk that stores data of the second LUN. When data of a first LUN is stored on a disk which contains data of a second LUN, then the two LUNs are said to overlap. Thus, the forcible relocation functionality provided by the LUN Manager 504 ensures that two LUNs do not overlap.
Within operating systems or within an application directly above the operating system, of host computers, an executable routine or component xe2x80x9cResolveObjectxe2x80x9d 506 has been developed to translate a logical object name 508 into one or more LUNs 510 on which the object is stored in a mass storage device. ResolveObject interacts with the file manager and volume manager, or with shared data structures employed by the file manager and volume manager, to translate logical object names into a list of LUNs. Both ResolveObject 506 and LUN Manager 504 provide necessary pieces of a logical-object-name-to-physical-location translation mechanism required by certain human users and APPs running on host computers. However, these separate functionalities are not currently linked, and it is difficult or impossible for a human user or APP to first use ResolveObject to translate a logical object name to a list of LUNs and then to directly access functionality provided by the LUN Manager 504 on a remote disk array 502 to obtain a physical translation of a logical object name and to employ the forced-move functionality provided by the LUN Manager in order to separate the set of LUNs that together compose a first logical object from the set of LUNs that together compose a second logical object so that the first logical object does not overlap the second logical object.
Thus, computer users, application program developers, database managers, database designers, and computer and mass storage device designers and manufacturers have all recognized the need for direct, easy-to-use logical object translation and logical object separation mechanisms that can be employed by human users and APPs to determine the physical locations of logical objects and to force and monitor separation of logical objects.
One embodiment of the present invention provides logical object to physical location translation to human users and APPs for logical objects stored on mass storage devices. In addition, this embodiment of the present invention provides tools with which a human user or APPs may separate two logical objects so that the two logical objects do not overlap on physical storage media and tools that allow a human user or APP to monitor the resulting separation of logical objects to detect subsequent re-overlap of the logical objects. This embodiment of the present invention makes use of already existing object resolution and LUN Manager functionalities developed for host computers and mass storage devices, respectively. This embodiment provides new interfaces to the object resolution and LUN Manager components, and provides direct interaction between these new interfaces.